1. Field of the Invention
The invention relates to authentication and, more particularly, how authentication is performed in a communication network according to the Internet Protocol Multimedia System (IMS) of the 3rd Generation Partnership Project (3GPP).
2. Description of the Prior Art
FIG. 1 shows the registration signaling flow for a user to become registered. For the purpose of this registration signaling flow, the subscriber UE is considered to be roaming. This flow also shows the authentication of the private user identity. The signaling flow is from 3GPP TS 24 228 V5.3.0 which is incorporated herein by reference in its entirety. In this signaling flow, the home network does not have an active network hiding configuration. The steps of registration are described in a sequence following with the numbered paragraphs below which correspond to the numbered steps of FIG. 1:                1. GPRS Attach/PDP Context Establishment and proxy call state control function (P-CSCF) Discovery (UE to GPRS)                    This signaling flow is shown to indicate prerequisites for the registration signaling.                        2. REGISTER request (UE to P-CSCF)                    The purpose of this request is to register the user's SIP URI with a serving call state control function (S-CSCF) in the home network. This request is routed to the P-CSCF because it is the only SIP server known to the UE. In the following SIP request, the Contact field contains the user's host address.            The P-CSCF performs two actions, binding and forwarding. The binding is between the User's SIP address (user1_public1@home1.net) and the host (terminal) address ([5555::aaa:bbb:ccc:ddd]) which was acquired during PDP context activation process.                        
Request-URI:The Request-URI (the URI that follows the methodname, “REGISTER”, in the first line) indicates thedestination domain of this REGISTER request. The rulesfor routing a SIP request describe how to use directoryname service (DNS) to resolve this domain name(“registrar.home1.net”) into an address or entry point intothe home operator's network (the I-CSCF). This infor-mation is stored in the USIM.Via:IPv6 address of the SIP session allocated during the PDPContext Activation process.From:This indicates the public user identity originating theREGISTER request. The public user identity may beobtained from the USIM.To:This indicates the public user identity being registered.This is the identity by which other parties know thesubscriber. It may be obtained from the USIM.Contact:This indicates the point-of-presence for the subscriber -the IP address of the UE. This is the temporary point ofcontact for the subscriber that is being registered. Sub-sequent requests destined for this subscriber will be sentto this address. This information isstored in the P-CSCF and S-CSCF.Authorization:It carries authentication information. The private useridentity (user1_private@home1.net) is carried in theuser name field of the Digest AKA protocol. The URIparameter (directive) contains the same value as theRequest-URI. The realm parameter (directive)contains the network name where the username isauthenticated. The Request-URI and the realm parameter(directive) value are obtained from the same field in theUSIM and therefore, are identical.Security-Client:lists the supported algorithm(s) by the UE.Supported:This header is included to indicate to the recipient thatthe UE supports the Path header.                                    Upon receiving this request the P-CSCF sets it's SIP registration timer for the UE to the Expires time in the request.                        3. DNS:DNS-Q                    Based on the user's URI, the P-CSCF determines that UE is registering from a visiting domain and performs the DNS queries to locate the interrogating call state control function (I-CSCF) in the home network. The look up in the DNS is based on the address specified in the Request URI.            The P-CSCF sends the REGISTER request—after local processing—to the address indicated in the Request-URI. When forwarding the REGISTER request, the P-CSCF needs to specify the protocol, port number and IP address of the I-CSCF server in the home network to which to send the REGISTER request. The P-CSCF tries to find this information by querying the DNS. Since the Request-URI does not specify a numeric IP address, and the transport protocol and port number are not indicated, the P-CSCF performs a naming authority pointer (NAPTR) query for the domain specified in the Request-URI.            Once the IP address of the I-CSCF is obtained, the P-CSCF forwards the REGISTER request to this IP address (i.e. 5555::aba:dab:aaa:daa) using the UDP protocol and port number 5060.                        4. REGISTER request (P-CSCF to I-CSCF)                    The P-CSCF needs to be in the path for all mobile originated and mobile terminated requests for this user. To ensure this, the P-CSCF adds itself to the Path header value for future requests.            The P-CSCF binds the public user identity under registration to the Contact header supplied by the user.            The P-CSCF adds also the P-Visited-Network-ID header with the contents of the identifier of the P-CSCF network. This may be the visited network domain name or any other identifier that identifies the visited network at the home network.            This signaling flow shows the REGISTER request being forward from the P-CSCF to the I-CSCF in the home domain.                        
Path:This is the address of the P-CSCF and is includedto inform the S-CSCF where to route terminatingsessions.Require:This header is included to ensure that the recipientcorrectly handles the Path header. If the recipientdoes not support the path header, a response willbe received with a status code of 420 and anUnsupported header indicating “path”. Such aresponse indicates a misconfiguration of therouting tables and the request has beenrouted outside the IM CN subsystem.P-Visited-Network-ID:It contains the identifier of the P-CSCF networkat the home network.P-Charging-Vector:The P-CSCF inserts this header and populates theIMS Charging Id (ICID) parameters with a uniquevalue and the IP address of the P-CSCF.                5. Cx: User registration status query procedure                    The I-CSCF makes a request for information related to the Subscriber registration status by sending the private user identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF required capabilities and the I-CSCF uses this information to select a suitable S-CSCF.            For detailed message flows see 3GPP TS 29.228.                        6. REGISTER request (I-CSCF to S-CSCF)                    I-CSCF does not modify the Path header.            This signaling flow forwards the REGISTER request from the I-CSCF to the S-CSCF selected.            Path: The S-CSCF stores the contents of the Path header and uses the URI for routing mobile terminated sessions.            Upon receiving this request the S-CSCF may set its SIP registration timer for this UE to the Expires time in this request or the S-CSCF may assign another registration timer for this registration.                        7. Cx: Authentication procedure                    Since the REGISTER request arrived without integrity protection to the P-CSCF, the S-CSCF shall challenge it. For this, the S-CSCF requires at least one authentication vector to be used in the challenge to the user. If a valid authentication vector (AV) is not available, then the S-CSCF requests at least one AV from the HSS.            The S-CSCF indicates to the HSS that it has been assigned to serve this user.            For detailed message flows see 3GPP TS 29.228.                        8. Authentication vector selection                    The S-CSCF selects an authentication vector for use in the authentication challenge. For detailed description of the authentication vector, see 3GPP TS 33.203.            The authentication vector may be of the form as in 3GPP TS 33.203 (if IMS AKA is the selected authentication scheme):                            AV=RANDn∥AUTNn∥XRESn∥CKn∥IKn where:                                    RAND: random number used to generate the XRES, CK, IK, and part of the AUTN. It is also used to generate the RES at the UE.                    AUTN: Authentication token (including MAC and SQN).                    XRES: Expected (correct) result from the UE.                    CK: Cipher key (optional).                    IK: Integrity key.                                                                                9. 401 Unauthorized response (S-CSCF to I-CSCF)                    The authentication challenge is sent in the 401 Unauthorized response towards the UE.            WWW-Authenticate: The S-CSCF challenges the user. The nonce includes the quoted string, base64 encoded value of the concatenation of the AKA RAND, AKA AUTN and server specific data. The S-CSCF appends also the Integrity Key (IK) and the Cyphering key (CK).            The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it may look like: nonce=“A34Cm+Fva37UYWpGNB34JP”.                        10. 401 Unauthorized response (I-CSCF to P-CSCF)                    The authentication challenge is sent in the 401 Unauthorized response towards the UE.                        11. 401 Unauthorized response (P-CSCF to UE)                    The P-CSCF removes any keys received in the 401 Unauthorized response and forwards the rest of the response to the UE.            WWW-Authenticate: The P-CSCF removes the IK and CK parameters (directives) from the header.                        12. Generation of response and session keys at UE                    The UE calculates the response, RES, and also computes the session keys IK and CK. The RES is put into the Authorization header and sent back to the registrar in the REGISTER request.                        13. REGISTER request (UE to P-CSCF)                    Authorization: This carries the response to the authentication challenge received in step 11 along with the private user identity, the realm, the nonce, the URI and the algorithm.            This message is protected by the IPsec SA negotiated.                        14. DNS: DNS-Q                    This is according to step 3.                        15. REGISTER request (P-CSCF to I-CSCF)                    This signaling flow shows the REGISTER request being forwarded from the P-CSCF to the I-CSCF in the home domain.            Path: This is the P-CSCF URI and it is included to inform the S-CSCF where to route terminating sessions.                        16. Cx: User registration status query procedure                    The I-CSCF requests information related to the Subscriber registration status by sending the private user identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF name which was previously selected in step 5 (Cx: User registration status query procedure).            For detailed message flows see 3GPP TS 29.228.                        17. REGISTER request (I-CSCF to S-CSCF)                    This signaling flow forwards the REGISTER request from the I-CSCF to the S-CSCF.            Path: The S-CSCF stores the contents of the Path header and uses this URI for routing mobile terminated sessions.            P-Charging-Vector: The S-CSCF stores the contents of the ICID parameters for possible charging activities.                        18. Authentication                    Upon receiving an integrity protected REGISTER request carrying the authentication response, RES, the S-CSCF checks that the user's active, XRES matches the received RES. If the check is successful then the user has been authenticated and the public user identity is registered in the S-CSCF.                        19. Cx: S-CSCF registration notification procedure                    On registering a user the S-CSCF informs the HSS that the user has been registered at this instance. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF.            For detailed message flows see 3GPP TS 29.228.                        20. 200 OK response (S-CSCF to I-CSCF)                    The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful.            Service-Route: The S-CSCF inserts the Service-Route header value that includes the own S-CSCF URI.                        21. 200 OK response (I-CSCF to P-CSCF)                    The I-CSCF forwards the 200 (OK) response from the S-CSCF to the P-CSCF indicating that Registration was successful.                        22. 200 OK response (P-CSCF to UE)                    The P-CSCF saves the value of the Service-Route header and associates it with the UE. The P-CSCF then forwards the 200 (OK) response from the I-CSCF to the UE indicating that Registration was successful.                        
The 3GPP Technical Specification 24.229, which is incorporated by reference in its entirety, in Chapter 5.1.1.1A discusses that a subscriber has multiple IMS Public User Identities (IMPUs) and a single IMS Private User Identity (IMPI). The IMPUs are either explicitly registered or implicitly registered using messages of the Session Initiation protocol (SIP). As a result, the identity to be used for message origin verification in the P-CSCF is still open.
In IMS the user is authenticated in the S-CSCF during registration as has been discussed above. The message origin verification is delegated from the S-CSCF to the P-CSCF. Currently it is not clear how the message origin verification can be done in the P-CSCF. The IMPI is not present in messages other than REGISTER requests and using the IMPUs for this purpose is not appropriate.
One possibility is to include the IMPI into all of the messages initiated by the UE. However this solution is not safe as it exposes the user's IMPI on the air interface.
Currently in 3GPP the implicitly registered IMPUs are transferred from the Home Subscriber Server (HSS) to the S-CSCF and from the S-CSCF to the P-CSCF. The P-CSCF then keeps the user's explicitly and implicitly registered IMPUs together with the session keys IK and CK. Whenever a message arrives, the P-CSCF verifies the integrity protection using IK, then verifies if the identity included in the From: (or RPI) header field relates to that specific IK or not. The Technical Specifications of 3GPP to date are incorporated herein by reference in their entirety.
The current detailed description of the registration and authentication procedure of the 3GPP Technical Specifications described above with reference to FIG. 1 relative to the present invention is summarized as follows:
When the UE sends a REGISTER request to the network, it includes the IMPI in the Authorization header field (possibly base64 encoded). The P-CSCF receives the request and forwards the request (step 4) to the S-CSCF unmodified.
On receiving a REGISTER request from an unauthenticated user, the S-CSCF (step 8) requires at least one authentication vector (AV) to be used in the challenge to the user. If a valid AV is not available, then the S-CSCF requests at least one AV from the HSS.
The S-CSCF sends a 401 Unauthorized response to the UE (steps 9-11) containing the RAND and AUTN parameters. This message also includes the session keys IK and CK. The P-CSCF removes and stores the IK and CK keys before forwarding the response to the UE.
Upon receiving the response from the S-CSCF, the UE uses the RAND parameter to derive the IK and CK keys (step 12).
The UE sends a new REGISTER request (step 13) to the network, including its IMPI which integrity protects the message using IK. Upon receiving the request, the P-CSCF verifies the integrity of the REGISTER request using IK and forwards (steps 15 and 17) the message to the S-CSCF only when the verification was successful. In addition, the P-CSCF needs to signal to the S-CSCF that this message was received with integrity protection. After receiving the request, the S-CSCF performs whatever action is needed to register the subscriber and returns a 200 OK response (steps 20-22) to the UE.
In IMS, the user is authenticated in the S-CSCF during registration. The message origin verification is delegated from the S-CSCF to the P-CSCF. Currently it is not clear how the message origin verification can be done in P-CSCF. The IMPI (IMS Private Identity) is not present in messages other than REGISTER requests and using the IMPUs (IMS Public Identity) for this purpose is not appropriate.